✨ Fiche d'Aide à la Décision
Document interactif — Tout s'ouvre directement dans le navigateur
Document Word Original
Visualisation du document DOCX converti en HTML. Tout le contenu est éditable.
FAD
-
DOCUMENT D’ANALYSE FONCTIONNEL
-
FUNCTIONAL ANALYSIS DOCUMENT
Processus Achat
Microsoft Business Central
- ANAL
Sommaire
4. Traitement d‘une livraison directe 6
5. Saisie d’une demande de prix 7
6. Saisie d’une commande cadre 8
7. Saisie d’une commande d‘achat 10
8. Saisie d’un retour d’une commande achat 12
11. Annexe 1 : Liste d‘écarts 16
Ce document liste l’analyse fonctionnel sur les processus métier du client concernant le domaine des achats. Les principaux objectifs de l’analyse fonctionnel sont :
- Visiter les sites clients comme les usines, entrepôts et/ou bureaux
- Conduire des ateliers orientés processus.
- Ne pas rentrer en profondeur sur les fonctionnalités de l’ERP ni faire de démonstrations
- Comprendre la façon de travailler actuelle, les points faibles et les attentes globales et futures
- Identifier les écarts critiques et les interfaces qui peuvent avoir un impact sur le projet
- Identifier les volumes des référentiels et données transactionnelles
- Confirmer le périmètre fonctionnel, technique, géographique et organisationnel du projet
- Identifier un jeu de donnée nécessaire pour l’ERP pour mieux préparer les ateliers de démonstration.
Ce document a été préparé sur la base d‘atelier(s) réalisés avec les membres de l'équipe de projet suivants :
Atelier | Date | Lieu | Almakom | Client |
1er atelier | … | … | Nom et Prénom | Nom et Prénom |
2ème atelier | … | … | Nom et Prénom | Nom et Prénom |
Versions du document
Version | Date | Description | Ecrit par | Approuvé par |
Draft | JJ/MM/AAAA | Draft | Nom et Prénom | Nom et prénom |
… | JJ/MM/AAAA | … | … | … |
Membre de l‘équipe | Fonction | |
Nom et Prénom | … | … |
Nom et Prénom | … | … |
Les processus standards ERP qui font partie des ateliers d’analyse sur les achats sont :
3 Planification
3.1. Contexte et Hypothèses
**3.1. Contexte et Hypothèses**
Le processus d'achat du client est basé sur 3 types d'achats : projets, achats génériques société et achats mutualisés multi-projet. Les besoins projets sont anticipés ou constatés et sont achetés au niveau de chaque projet. Les achats sont suivis par une chaîne d'approbation basée sur un seuil dépendant de la personne qui passe la commande ou du risque sur la commande.
Les fonctionnalités souhaitées dans le système incluent le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système, l'intégration des coûts de transport lié à la commande et la prise en compte des différents plannings (fournisseur, transport, etc.).
Les hypothèses retenues sont :
* La nécessité d'avoir les certificats pour toutes les petites commandes n'est pas systématique.
* Le processus de contrôle qualité est détaillé et doit être défini avec le responsable qualité.
* Les lignes budget doivent inclure les champs pour remonter le coût budgété ou le montant réel dans la commande.
* Les dates de planification dans les lignes projet doivent être renseignées.
Les éléments incertains ou dépendants d'autres facteurs susceptibles d'influencer la suite du projet sont :
* La stratégie de migration à organiser pour discuter de l'historique.
* La mise en place d'un flux d'approbation formalisé.
* La définition du processus détaillé d'inspection de contrôle qualité.
**INFORMATION MANQUANTE**
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
3.2. Schéma des processus ERP : Planification 1.0
3.3. Principales règles de gestion
- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le "fichier article" doit être paramétré pour prendre en compte les différents types d'articles (en stock, non inventory, service).
- Les "fournisseurs" doivent être organisés par spécialité pour faciliter la gestion des commandes.
- Le "numéro de projet" est obligatoire sur le "dévis" pour lier la commande au projet.
- Les "documents de contrôle qualité" doivent être créés avec rattachement de photos et tracking lot et série.
- La "réception" est validée après validation qualité par le responsable qualité.
- Les "lignes budget" doivent être paramétrées pour remonter le coût budgété ou le montant réel dans la commande.
- Les "dates de planification" dans les lignes projet doivent être renseignées pour permettre la consommation sur le projet.
3.4. Documents et statistiques
Planification
3.4. Documents et statistiques
La planification des achats est un processus clé pour garantir la disponibilité des matières premières et des composants nécessaires pour les projets. Les documents et statistiques suivants sont utilisés pour soutenir ce processus :
- Fiche article : permet de stocker les informations sur les articles, tels que les caractéristiques techniques, les spécifications et les certifications.
- Journal des achats : permet de suivre les achats effectués, y compris les quantités, les dates de livraison et les coûts.
- Workflow validation : permet de définir les étapes de validation pour les achats, y compris la vérification des documents et la validation des factures.
- Tableau de bord adapté au profil pour l'utilisateur : permet de visualiser les informations pertinentes pour chaque utilisateur, telles que les commandes en attente, les livraisons à venir et les stocks disponibles.
- Export facile dans Excel : permet de exporter les données des documents et statistiques dans un format Excel pour une analyse plus approfondie.
Les types d'articles suivants sont pris en compte dans la planification des achats :
- En stock : les articles qui sont stockés dans les entrepôts.
- Non inventory : les articles qui ne sont pas stockés, tels que les services.
- Service : les services qui sont fournis par les fournisseurs.
La gestion du multi-sourcing est également importante pour garantir la disponibilité des matières premières et des composants. Cela implique de gérer plusieurs fournisseurs pour un même article et de suivre les quantités et les coûts associés à chaque fournisseur.
Les informations de planning suivantes sont également importantes pour la planification des achats :
- Lead-time : le temps nécessaire pour recevoir les articles des fournisseurs.
- Stock de sécurité : le niveau de stock minimum nécessaire pour garantir la disponibilité des articles.
- Minimum Order Quantity : la quantité minimale que les fournisseurs sont prêts à livrer.
- Vacances des fournisseurs et transporteurs : les périodes pendant lesquelles les fournisseurs et les transporteurs sont en vacances.
La création d'un Warehouse receipt est également importante pour suivre les articles reçus et les quantités disponibles. Le processus de réception doit être défini avec le responsable qualité pour garantir que les articles reçus sont conformes aux spécifications.
3.5. Volume des données
Planification du volume des données
Le processus de planification du volume des données est essentiel pour garantir que les besoins des achats sont satisfaits. Les achats sont classés en trois types : projets, achats génériques société et achats mutualisés multi-projet.
Les besoins projets sont anticipés ou constatés et donnent lieu à des achats spécifiques optimisés. Ces achats sont réalisés en fonction de la conception détaillée et de la consommation des pièces standard du stock. Les pièces nécessaires au-delà du stock sont achetées séparément.
Le processus de planification du volume des données comprend également la gestion des certificats par la Qualité Contrôle. Les certificats sont nécessaires pour certaines commandes, mais pas pour toutes.
Dans Microsoft Dynamics 365 Business Central, le tableau de bord adapté au profil de l'utilisateur est utilisé pour afficher les informations pertinentes. Les données sont exportées facilement dans Excel.
Les informations de planning, telles que le lead-time, le stock de sécurité et le Minimum Order Quantity, sont également prises en compte dans le processus de planification du volume des données. Les achats sont réalisés en fonction de ces informations pour garantir que les besoins sont satisfaits.
La gestion du multi-sourcing, y compris la référence fournisseur, est également essentielle dans le processus de planification du volume des données. Les achats sont réalisés en fonction de la disponibilité des fournisseurs et de leurs capacités de livraison.
Enfin, les "Purchase quote" (demande d'offre) sont utilisées pour obtenir des offres de fournisseurs et les comparer pour choisir le meilleur fournisseur. Les offres sont ensuite transformées en commandes en 1 clic.
3.6. Écarts critiques et interfaces
Identification des écarts critiques et interfaces nécessaires entre le processus actuel et les bonnes pratiques ou les exigences cibles du projet.
**Écarts critiques :**
* L'absence de contrôle qualité systématique à la réception, ce qui peut entraîner des problèmes de qualité et de sécurité.
* La nécessité de prendre en photo chaque colis reçu pour assurer la traçabilité.
* La difficulté à déterminer à qui est destiné chaque colis à la réception.
* La facture non payée tant que la non-conformité n'est pas résolue.
* Les acomptes demandés par certains fournisseurs.
* L'absence de document d'entrée en stock, ce qui peut entraîner des problèmes de gestion des stocks.
**Interfaces nécessaires :**
* Intégration des coûts de transport liés à la commande.
* Suivi de la confirmation de commande fournisseur.
* Date de livraison renseignée dans le système.
* Gestion des coûts de projet avec les Work-Packages.
* Suivi des lead times fournisseurs.
* Prise en compte des différents plannings (fournisseur, transport, spécialité).
* Numéro de projet obligatoire sur le devis pour lier la commande au projet.
* Documentation à joindre à la demande de devis.
* Utilisation des champs Due Date et Requested Receipt Date.
**Objets BC concernés :**
* Fiche article
* Journal des achats
* Workflow validation
* Gestion des stocks
* Gestion des coûts de projet
* Gestion des fournisseurs
* Gestion des incoterms
**Informations manquantes :**
* Processus d'approbation formalisé pour les commandes.
* Définition du processus détaillé d'inspection qualité.
* Définition des champs pour remonter le coût budgété ou le montant réel dans la commande.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
4 Traitement d‘une livraison directe
4.1. Contexte et Hypothèses
Traitement d'une livraison directe
Contexte et hypothèses
Le client utilise Microsoft Dynamics 365 Business Central pour gérer ses achats et ses projets. Le processus de traitement des livraisons directes est actuellement manuel et nécessite une inspection qualité systématique à la réception. Le client souhaite mettre en place un flux d'approbation formalisé pour les commandes et souhaite intégrer les coûts de transport liés à la commande.
Les hypothèses retenues pour ce processus sont les suivantes :
* Le client souhaite utiliser le système pour suivre la confirmation de commande fournisseur et la date de livraison.
* Le client souhaite intégrer les coûts de transport liés à la commande.
* Le client souhaite supprimer l'inspection systématique à la réception et remplacer par un contrôle qualité léger ou approfondi donné par le Chef de Projet.
* Le client souhaite scanner les documents avec la pièce pour assurer la traçabilité.
* Le client souhaite utiliser les champs "Due Date" et "Requested Receipt Date" pour gérer les lead times fournisseurs et les plannings.
Les éléments organisationnels ou techniques pouvant influencer le fonctionnement de ce processus sont les suivants :
* La gestion des projets avec des Work-Packages, des dates, des quantités et des budgets.
* La gestion des certificats par la Qualité Contrôle.
* La prise en compte des différents plannings (fournisseur, transport, spécialité).
* La gestion des Incoterms et des champs "Shipment Method Code" et "Due Date".
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
4.2. Schéma des processus ERP : Traitement d’une livraison directe 2.0
4.3. Principales règles de gestion
- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le "Warehouse receipt" est créé pour suivre les lots de pièces reçues. La qualité doit valider le processus avant de renseigner les informations de réception.
- Les certificats sont gérés par la Qualité Contrôle.
- Les photos des colis reçus sont prises avant et après ouverture.
- Les Non Conformités (NC) sont traitées avec le fournisseur, avec éventuel paiement en avance.
- Les pièces VOL sont livrées avec des certificats.
- Les lieux de stockage sont : Payerne.
- Le suivi des lead times fournisseurs est effectué.
- Les différents plannings (fournisseur, transport, spécialité) sont pris en compte.
- Le numéro de projet est obligatoire sur le devis pour lier la commande au projet.
- La documentation est jointe à la demande de devis.
- Les champs "Due Date" et "Requested Receipt Date" sont utilisés.
- Le devis est lié à la commande.
- La gestion des Incoterms est effectuée en utilisant le champ "Shipment Method Code".
- Lorsqu'un Incoterm est renseigné, la ville doit être précisée.
- Le numéro de projet et les tâches projet sont renseignés sur les lignes pour permettre la consommation sur le projet.
- La réception est validée après validation qualité.
- Le responsable qualité définit le processus d'inspection.
- Un document de contrôle qualité est créé avec rattachement de photos.
- Le tracking lot et série est effectué.
- Les lignes budget ont des champs pour remonter le coût budgété ou le montant réel dans la commande.
- Les dates de planification sont renseignées dans les lignes projet.
4.4. Documents et statistiques
Génération de documents et statistiques pour le processus de livraison directe
Dans le cadre d'une livraison directe, les documents suivants doivent être générés :
- Fiche de réception de stock (Warehouse Receipt) pour suivre les lots et les séries de pièces reçues.
- Document de contrôle qualité pour valider la réception des pièces et les photos associées.
- Fiche de commande (Make Order) pour lier la commande au projet et aux tâches projet.
- Journal des achats pour suivre les commandes passées et les livraisons reçues.
Les états et statistiques nécessaires pour suivre le processus sont :
- Tableau de bord adapté au profil de l'utilisateur pour afficher les informations pertinentes.
- Export en Excel pour analyser les données en détail.
- Suivi des lead times fournisseurs pour planifier les commandes et les livraisons.
- Prise en compte des différents plannings (fournisseur, transport, etc.) pour optimiser les opérations.
- Gestion des coûts dans les lignes budget pour remonter les coûts budgétés ou les montants réels dans la commande.
Il est important de noter que la gestion des certificats et des documents de contrôle qualité doit être effectuée par la Qualité Contrôle.
4.5. Volume des données
Traitement d'une livraison directe
Le processus de traitement d'une livraison directe implique plusieurs étapes :
1. **Réception** : Le colis reçu est pris en photo et scanné avec la pièce pour assurer la traçabilité.
2. **Contrôle qualité** : Le responsable qualité valide la réception en créant un document de contrôle qualité avec rattachement de photos, tracking lot et série.
3. **Validation** : La réception est validée lorsque le responsable qualité valide le document de contrôle qualité.
4. **Gestion des pièces** : Les pièces reçues sont gérées en fonction de leur type (en stock, non inventory ou service).
5. **Suivi des certificats** : Les certificats sont gérés par la Qualité Contrôle pour les pièces VOL.
**Volume des données** :
* **Données référentielles** : Les données référentielles concernent les fournisseurs, les articles, les projets, les commandes, les réceptions, les contrôles qualité, etc.
* **Nombre de documents ou transactions** : Le nombre de documents ou transactions générés par période est [INFORMATION MANQUANTE].
* **Période** : La période concernée est [INFORMATION MANQUANTE].
**Objets BC** :
* **Fiche article** : La fiche article est utilisée pour gérer les articles en stock, non inventory ou service.
* **Journal des achats** : Le journal des achats est utilisé pour suivre les commandes et les réceptions.
* **Workflow validation** : Le workflow validation est utilisé pour valider les réceptions et les contrôles qualité.
* **Warehouse receipt** : Le warehouse receipt est utilisé pour suivre les réceptions et les pièces reçues.
4.6. Écarts critiques et interfaces
Traitement d'une livraison directe
Écarts critiques et interfaces :
- **Écart 1 :** Absence de document d'entrée en stock. La qualité doit valider le processus de réception, mais il n'y a pas de document pour contrôler les quantités et les pièces reçues.
- **Écart 2 :** Difficulté pour le chef de projet à contrôler les quantités et les pièces reçues.
- **Écart 3 :** Pas de suivi des certificats pour toutes les petites commandes.
- **Écart 4 :** Pas d'inspection systématique à la réception.
- **Écart 5 :** Le Chef de Projet (CP) donne l'instruction de faire un contrôle qualité léger ou approfondi, mais il n'y a pas de processus défini pour l'inspection.
- **Écart 6 :** L'ingénieur ou le CP discute directement avec le fournisseur en cas de non-conformité, mais il n'y a pas de processus défini pour la résolution des non-conformités.
- **Écart 7 :** Facture non payée tant que la non-conformité n'est pas résolue.
- **Écart 8 :** Certains fournisseurs demandent des acomptes.
- **Écart 9 :** À la réception, l'atelier scanne les documents avec la pièce pour assurer la traçabilité, mais il n'y a pas de processus défini pour la gestion des documents.
- **Écart 10 :** Toutes les pièces VOL sont livrées avec des certificats, mais il n'y a pas de processus défini pour la gestion des certificats.
**Interfaces nécessaires :**
- **Interface 1 :** Intégration des coûts de transport lié à la commande.
- **Interface 2 :** Suivi des lead times fournisseurs.
- **Interface 3 :** Prise en compte des différents plannings : planning fournisseur, planning transport, fournisseurs organisés par spécialité.
- **Interface 4 :** Gestion des Incoterms : utilisation du champ Shipment Method Code, ville à préciser lorsqu'un Incoterm est renseigné.
- **Interface 5 :** Gestion des lignes budget : champs pour remonter le coût budgété ou le montant réel dans la commande.
- **Interface 6 :** Gestion des dates de planification dans les lignes projet.
- **Interface 7 :** Gestion des photos et des documents de contrôle qualité.
- **Interface 8 :** Gestion des certificats pour les pièces VOL.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
5.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
- Schéma des processus ERP : Demande de prix 3.0
5.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
5.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
5.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
5.6. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
6.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
6,2, Schéma des processus ERP : Saisie d’une commande cadre 4.0
6.3. Schéma des processus ERP : Saisie d’une commande d’achat
6.4. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
6.5. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
6.6. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
6.7. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).
7 Saisie d’une commande d‘achat
7.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
7.2 Schéma des processus ERP : Saisie d’une commande d’achat
7.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
7.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
7.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
7.6. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).
8 Saisie d’un retour d’une commande achat
8.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
8.2. Schéma des processus ERP : Saisie d’un retour d’une commande achat 6.0
8.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
8.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
8.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
8.6. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
9.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
9.2 Schéma des processus ERP : Rapport achat 8.0
9.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
9.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
9.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
9.6. Ecarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
10.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
10.2 Schéma des processus ERP : Historique achat 9.0
10.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
10.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
10.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
10.6. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
11.1. Liste d’écarts
La liste d’écart doit être initialisée et finalisée à la fin de la phase d’analyse.
Indiquer l’URL où la liste des écarts sera stockée (SharePoint / Teams / DevOps / Autre).
Contenu par Sections
Contenu organisé par sections avec édition individuelle.
3.1. Contexte et Hypothèses
3.3. Principales règles de gestion
3.4. Documents et statistiques
3.5. Volume des données
3.6. Écarts critiques et interfaces
4.1. Contexte et Hypothèses
4.3. Principales règles de gestion
4.4. Documents et statistiques
4.5. Volume des données
4.6. Écarts critiques et interfaces
Édition Avancée
Modifiez le document complet avec des outils avancés.